On a high level, attribute-based access control (ABAC) may be defined as a method where a subject's requests to perform operations on resources are granted or denied based on assigned attributes of the subject, assigned attributes of the resource, environment conditions, and a set of one or more policies that are specified in terms of those attributes and conditions. Here, attributes are characteristics of the subject, resource, or environment conditions. Attributes contain information given by a name—value pair. A subject is a human user or non-person entity, such as a device that issues access requests to perform operations on resources. Subjects are assigned one or more attributes. A resource (or object) is a system resource for which access is managed by the ABAC system, such as devices, files, records, tables, processes, programs, networks, or domains containing or receiving information. It can be the resource or requested entity, as well as anything upon which an operation may be performed by a subject including data, applications, services, devices, and networks. An operation is the execution of a function at the request of a subject upon a resource. Operations include read, write, edit, delete, copy, execute and modify. Environment conditions describe an operational or situational context in which an access request occurs. Environment conditions are detectable environmental characteristics. Environmental characteristics are generally independent of subject or resource, and may include the current time, day of the week, location of a user, or the current threat level. Finally, policy is the representation of rules or relationships that makes it possible to determine if a requested access should be allowed, given the values of the attributes of the subject, resource, and possibly environment conditions. A policy may be expressed as a logical function, which maps an access request with a set of attribute values (or references to attribute values) to an access decision (or an indication that the request has not returned a decision).
An ABAC authorization scenario is depicted in FIG. 3. In step 1, a user (or subject) 301 requests access to a resource 151 through the intermediary of an ABAC mechanism 302 which selectively protects access to the resource 151. The ABAC mechanism 302 forms a decision by retrieving, in step 2a-2b-2c-2d, applicable rules R1, R2, R3 from a policy repository 190, subject attributes (e.g. name, affiliation, clearance) from a subject attribute data source 303, resource attributes (e.g. type, owner, classification) from a resource attribute data source 304, and environment conditions expressed as environment attribute values from an environment attribute data source 305. If the ABAC mechanism 302 is able to determine that the decision is to permit access, it will take appropriate measures to grant the user 301 access to the resource 151, e.g. by selectively deactivating a hardware or software protection means. Otherwise, access to the resource 151 may be denied.
There currently exist general-purpose ABAC policy languages that have the richness to express fine-grained conditions and conditions which depend on external data. A first example is the Extensible Access Control Markup Language (XACML) which is the subject of standardization work in a Technical Committee of the Organization for the Advancement of Structured Information Standards (OASIS, 35 Corporate Drive Suite 150, Burlington, Mass. 01803-4238, USA). A policy encoded with XACML consists of declarative (in particular, functional) expressions in attribute values, and the return value (decision) of the policy is one of Permit, Deny, Not Applicable, or Indeterminate. An XACML policy can apply to many different situations, that is, different subjects, resources, actions and environments and may give different results for them. The XACML specification defines how such a request is evaluated against the policy, particularly what policy attributes are to be evaluated or, at least, which values are required to exist for a successful evaluation to result. A key characteristic of this evaluation process is that the request must describe the attempted access to a protected resource fully by containing information sufficient for all necessary attribute values to be retrieved. In practice, it may be that the request is interpreted in multiple stages by different components, so that a PEP (Policy Enforcement Point) issuing the requests provides only some attribute values initially, and a PDP (Policy Decision Point) or other component responsible for the evaluation can dynamically fetch more values from remote sources as they are needed. A second example is the Axiomatics Language For Authorization™, which the applicant provides.
XACML-based solutions typically offer “authorization as a service”, wherein a PEP in a target application/system captures access requests in real time and sends them to a PDP for evaluation against a current version one or more XACML policies. Such externalized authorization approach ensures continuity in that it drastically reduces or eliminates the latency between an update of the policy and actual enforcement of the new rules therein.
In practice, however, many organizations operate computer systems for which there are currently no PEP components available, and whose authorization mechanisms are built around other models than ABAC. In the category of non-externalized non-ABAC authorization models, there is a practice of associating each resource in the system with a record naming principals of the system and the actions they are entitled to perform on the resource. As used herein, a principal may be a user (person or non-person entity) or a group of users. It is common practice to require authentication of users of a system with access control of this type; the authentication may be performed in connection with a login procedure. Principals may be non-distinct, in that a given user may be defined as a principal on its own or may be included in one or more groups; it is the responsibility of the system administrator to assign access rights in a manner that avoids inconsistencies and/or to define precedence rules (e.g. “first applicable”, “deny overrides”, “permit overrides”) suitable for reconciling any contradictory access decisions stemming from a user's ability to act as more than one principal in the system. With this in place, it is typically possible to treat all principals in a uniform manner irrespective or their status as single users or groups. The records naming principals and their corresponding access rights to a resource, in non-ABAC authorization models, are commonly referred to as access control lists (ACLs). ACLs may be stored in a central or distributed memory in the computer system together with an indication of the resource(s) to which they refer. One ACL may be applicable in respect of more than one resource; inheritance between hierarchically ordered resources (e.g. folder-subfolder-file) is widely practiced as well. The rights defined by an ACL are enforced by an access control mechanism taking measures to restrict or facilitate a principal's access, as required by the ACL, to a resource. In different system architectures, the access control mechanism may relate to separate components of the computer system (e.g. access control module interposed between a user interface and a protected resource) or may be integrated into components with additional responsibilities (e.g. a database interface configured to reply only to such queries that have passed an authorization test against an applicable ACL). ACLs have been used as one way to implement so-called role-based access control (RBAC).
One limitation of ACL-based authorization is that certain policies are impossible to express as regular ACLs, e.g. policies which refer to resource metadata other than the resource identity. In particular, rules based on conditions on the current location of the principal relative to the location of the resource cannot be satisfactorily expressed as standard ACLs, unless a principal is assumed to be always in the same location. Calendar dependencies represent a further challenging class of conditions; attempts to overcome this limitation include scheduled recalculation of existing user sessions, whereby a users may be regrouped as different principals, which may however be a solution less appreciated by users of the computer system.
A further limitation is the scaling problems of policies expressed as ACLs. A desired increase in one of principal count, resource count or policy complexity typically happens at a significant cost increase in terms of storage space and processing power, and may lead to the access control mechanism consuming a larger share of the available storage and processing capacity in the system. There is an inherent trade-off between policy complexity on the one hand, and increased security risk and maintenance cost on the other. The enforcement of too complex policies is rendered infeasible by the burden of maintaining the ACLs and of reorganizing resources for access control purposes (e.g. arranging files with similar access rights in a common folder to exploit inheritance), particularly for large sets of resources. Tools for maintaining distributed ACLs, such as specialized scripts and schedulers, have been proposed to help system administrators spend less time on ACL maintenance; by their ad hoc nature, these tools may however be less reliable than the proprietary access control mechanism of the system (e.g. by lacking a systematic testing and verification history) and could therefore put the overall reliability of the access control functionality in jeopardy.